home *** CD-ROM | disk | FTP | other *** search
/ Amiga Collections: Bavarian / Bavarian #176 (19xx)(APS Electronic).zip / Bavarian #176 (19xx)(APS Electronic).adf / Tetriz1 / tetriz.docs < prev    next >
Text File  |  1988-08-09  |  21KB  |  526 lines
  1.  
  2.                         Page #1
  3. OutLine of Documentation
  4.  
  5.    1-3... This document has 3 pages relating to tetriz
  6.    4-6... Section on general programming tips
  7.    7-8... Section critizing poor programming efforts on Amiga
  8.    9  ... Greetings + Mailing Address
  9.  
  10. *************************************************************************
  11. *************************************************************************
  12. *************************************************************************
  13. One - tetriz
  14. *************************************************************************
  15. *************************************************************************
  16. *************************************************************************
  17.  
  18.    Welcome to Amiga Tetriz by Andy Hook
  19.  
  20.    These are some of the thoughts behind my release of this source code:
  21.  
  22.       I've been programming for a while now, and in looking back,
  23.       I wish that I'd known, when I first started programming,
  24.       the tricks and shortcuts that I know and use now.
  25.  
  26.       I guess learning may be a kind of snowball effect, and a
  27.       good push seems to sometimes get the ball rolling that much
  28.       faster.
  29.  
  30.       Tetriz itself, I think tetriz is a good example of
  31.       addictive game design.  The game operates under a rule
  32.       based system allowing you to anticipate the effects of
  33.       any action - before you make it... your own successes or
  34.       failures accumulate to spell your final outcome...the
  35.       game is crisp, bright.  The components of the graphics,
  36.       sound and rules all stand out in bright contrast within
  37.       themselves, not mushy and vague like most games.  The rules
  38.       in particular are meaningful within the scope of the game,
  39.       not capricious and arbitrary.
  40.  
  41.       In regards to releasing "Tetriz" to the public domain.
  42.  
  43.  
  44.       Additionally I would like to encourage other developers
  45.       to breed good programmers, and to help out the community
  46.       at large rather than maliciously profiting off their own
  47.       "secret" technical knowledge in lieu of any ability to
  48.       come up with good product concepts.
  49.  
  50.    Feel free to browse the source code, use it, learn from it.
  51.  
  52.                         Page #2
  53.    In tetriz I have attempted to teach in a certain way:
  54.  
  55.       To *not* teach instruction opcodes, but to teach instruction
  56.       routines, or techniques.  I believe that the programmer finds
  57.       the opcode to suit the logic operation, not visa versa.
  58.  
  59.       To demonstrate the nitty-gritty of various technical aspects,
  60.       without relying on black-box style magical system functions.
  61.  
  62.    My past experience as a novice M.L. programmer showed a personal
  63.    weakness in Amiga specific technical knowledge.  I believe this
  64.    source code should demonstrate most technical aspects required for
  65.    a complete Amiga project.  Another tremendous help now is the
  66.    new Amiga Techical Reference Manual.
  67.  
  68.    A weakness, which I see in some other programmers, is their not
  69.    having a "mental-library" of approaches to any particular
  70.    algorithm.
  71.  
  72.    I believe this is due to magazines focusing on the crudest aspects
  73.    of teaching Machine Code, the opcodes themselves, versus what to do
  74.    with them.  Really there is no public avenue for a programmer to
  75.    become truly competent at any particular system.
  76.    (And I think this is a shame because I am sure that there are many
  77.     potential programmers who could easily blow me away...I mean if I
  78.    can learn to program - and I'm no shining example of intelligence -
  79.    then anybody should be able to learn to program)
  80.  
  81.    I hope that you enjoy this source and that you write many wonderful
  82.    games for me to play!
  83.  
  84.    If I get a positive reaction to this release I may write other
  85.    products for the public domain...(what the hell, it pays about the
  86.    same as my freelance work and its twice as fun).
  87.  
  88.    Other topics I may cover: A public domain replacement for QBak,
  89.    covering aspects of DOS from AmigaDos to raw MFM.
  90.  
  91.    You can mail me at:
  92.       Andy Hook
  93.       c/o The Computer Shop
  94.       3515 18th St SW Calgary Alta CANADA!
  95.       T2T-4T9
  96.  
  97.    FAX:   (403) 246-2861   (Daytime only please)
  98.    Online:   (403) 246-1858   24hr (Andy Hook c/o sysop), name:AMUC,pass:SIG
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.                         Page #3
  106.    Notes:
  107.  
  108.    You will find that I do not use macros or include files.   My
  109.    language outputs macro-contents in an Aztek compatible stream
  110.    and typically for machine code I don't really find a need for
  111.    include files.  I suggest the use of macros normally.
  112.  
  113.    Note that I have used a very formal coding style, I would recommend
  114.    a less commented style for most normal programming jobs.
  115.  
  116.    I don't suggest using Aztek.
  117.    I use Aztek by fault of the evil forces of Hydraulic Despotism [FH].
  118.  
  119.    I do suggest using CED.
  120.  
  121.    I wrote tetris during my "spare-time" (hah) after work, I wrote the
  122.    critical support routines first, once I had my mockup.
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.                         Page #4
  130. *************************************************************************
  131. *************************************************************************
  132. *************************************************************************
  133. Four - General Tips
  134. *************************************************************************
  135. *************************************************************************
  136. *************************************************************************
  137.  
  138.    Here is an example of what I consider to be good programming
  139.    practices:
  140.  
  141. ;----------------------------------------------------------------------------
  142. ;
  143. ;   SonyRoutine.asm © Mr. Good Code People Corp 1990 All Rights Reserved
  144. ;
  145. ;   *** On a copyright notice there are no extra spaces, commas, periods
  146. ;       or anything that might suggest that the copyright is not
  147. ;       directly bound to the named object and the named creator.
  148. ;       "All Rights Reserved" protects you;  In Canada mere creation
  149. ;       of a thing gives you implicit copyright, however I understand
  150. ;       that you must declare your rights.  Of course having rights
  151. ;       depends solely on your ability to enforce them.
  152.  
  153. ;       You should talk to your lawyer and work through the laws in
  154. ;       your state regarding copyrights.
  155.  
  156.  
  157.    include 'publics.i'
  158.  
  159. ;
  160. ;   This is an example of some good coding practices
  161. ;   Passed:
  162. ;      D0 = A Good Coding Practice Register
  163. ;
  164. SonyRoutine
  165.       move.l   d0,d1         ; D1 = My First Line
  166.       move.l   SonyAlpha(pc,d0.w),d5   ; D5 = My Second Line
  167.       lea   SonyVector(pc),a0   ; A0 = Another Line
  168.       move.l   SonyMemory(pc),a1   ; A1 = Yet another line
  169.       cmp.l   #0,a0         ; you can't "tst" a0
  170.       bne.s   SonyRoutine200
  171.       moveq   #40-1,d1      ; Show #,then -1 for dbf count
  172. SonyRoutine100
  173.       move.l   (a0)+,(a1)+      ; Lets Copy Something...
  174.       dbf   d1,SonyRoutine100
  175. SonyRoutine200
  176.       rts
  177.  
  178. SonyAlpha   dc.l   1,2,3,4,5,6,7,8
  179. SonyVector   dc.l   0
  180. SonyMemory   dc.l   'DISK'
  181.  
  182. ; end of routine.asm
  183. ;-----------------------------------------------------------------------------
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.                         Page #5
  192. ; Quick Comments on Above "Sony" Source Code
  193.  
  194. ;   When Labels are related, having the same header name like "Sony..."
  195. ;   makes them easier to see when searching a debuggers symbol list.
  196.  
  197. ;   Having long form names like "Routine" versus "Rtn" makes it easier
  198. ;   to remember what you are looking for, and what you are doing.
  199.  
  200. ;   Having comments always rigidly placed on a margin makes life much
  201. ;   easier for quick scanning through code
  202.  
  203. ;   Use PC Relative Code, (keep code modules to less than 64 K)
  204.  
  205. ;   Don't put comments on the same lines as Labels
  206.  
  207. ;   Don't have comments more than one line long unless left justified.
  208. ;   Comments don't go off the visible text editor screen to the right.
  209.  
  210. ;   When using fixed memory spaces, such as Amiga Hardware registers,
  211. ;   index off of A6 or some other definately free register (this speeds
  212. ;   up code tremendously, and reduces code size).
  213.  
  214. ;   Use bra.s moveq ect, unless your compiler optimizes automagically.
  215.  
  216. ;   Use Makefiles for MANX code, system takeover or not.
  217.  
  218. ;   When using MANX deal with the stupidity of 'publics' by putting
  219. ;   them all in one header file.
  220.  
  221. ;   The first line of any code segment should be the name
  222. ;   The last line of any code file should be the name
  223. ;   This makes printing much easier
  224.  
  225. ;   Machine Code doesn't flow visually very well when not aligned, don't
  226. ;   bother putting spaces at X if X is [ move.l (a0)+ X ,(a1)+ ]
  227. ;   Sometimes when I have a temporary line I will space it over one
  228. ;   from the left margin, versus actually tabbing it into a proper
  229. ;   position, this helps me remove all debugging code later.
  230.  
  231. ;   Learn to type without watching what you see on the screen for
  232. ;   feedback, Watching the screen slows you down to the speed of
  233. ;   your editors output.  (trust the audio and tactile cues...)
  234.  
  235. ;   Buy CED and MANX, buy ReSource, SEKA, RAW, CONVERTOR, AUDIOMASTER...
  236. ;   Buy DPAINT3 (for easy animation of character graphics).
  237.  
  238. ;   (CED will prevent accidents like losing source due to crash while
  239. ;   saving and is a phenomenal editor)
  240.  
  241. ;   You *must* have a hard-drive and at least 1 megabyte of memory
  242. ;   to program commercially.
  243.  
  244.  
  245.  
  246.  
  247.  
  248.                         PAGE #6
  249. ;   My only conceptual oriented suggestion:  When the conceptual going
  250. ;   gets tough, the tough modularize....  Any routine that becomes
  251. ;   unwieldy...just make the unwieldy part into a subroutine.  Remember
  252. ;   what makes programmers great isn't that they can program...anybody
  253. ;   can program, but programmers can INTEGRATE, using the massive
  254. ;   inferential ability that all human minds have; and that computers
  255. ;   (right now) don't.
  256.  
  257. ;   Writing Code is the easy part, with a little forethought a person
  258. ;   can sit down and basically produce a stream of code, the major
  259. ;   stumbling block is debugging.  My suggestion is don't make bugs...
  260. ;   but if you do here are some things you can do:
  261. ;
  262. ;      Have a state-trace-debugger to freeze the machine (I wish).
  263. ;
  264. ;      Write a fake-state-trace-debugger using 68xxx Trace Mode
  265. ;      (have it interupt driven, and detect mouse to stop)
  266. ;
  267. ;      Write some custom screen print routines to give you feedback
  268. ;      on bugs, or even just general occurances.
  269. ;
  270. ;      If you are not taking over the system, use MANX db.
  271. ;
  272.  
  273. ;   Some things I do:
  274. ;
  275. ;      I find it's more useful for me to write buglists/things-to-do
  276. ;      on small cards versus a whole sheet of paper.
  277. ;
  278. ;      I use tables a lot in my code, versus mulu's or shifts.
  279. ;      I write code for speed, not size; Amiga has tons of memory.
  280. ;
  281. ;      On the Amiga I use $bfe001 and $dff180 a lot for debugging...
  282. ;
  283. ;ClassicalExample:
  284. ;1$      add.w   #1,d0
  285. ;      move.w   d0,$dff180      ; Flash Screen
  286. ;      btst   #6,$bfe001      ; Wait till Mouse Pressed
  287. ;      bne.s   1$
  288. ;      rts
  289. ;
  290. ;      I try to think as much as I can before actually attacking
  291. ;      a project, this prevents design flaws.  But sometimes I will
  292. ;      force myself to start even if unprepared, this will catalyze
  293. ;      my thought process to action and then I can sit back and think
  294. ;      it through; kind of like zero-on-zero brainstorming.
  295. ;
  296. ;      I try to bring my computer as close to my natural enviroment
  297. ;      as possible; having a bed, bathroom, kitchen, soft huggable
  298. ;      female person all within reach is very important.
  299. ;      Exercise becomes important also.
  300. ;
  301. ;      Keep on the edge of available tools, available software and
  302. ;      latest news...Don't be afraid to read PC magazines.
  303. ;
  304. ;      Learn as much as possible from other programmers around you,
  305. ;      even if it is sometimes a humbling experience.
  306. ;
  307. ;   If you're going to work for your first company:
  308. ;
  309. ;      Make damn sure that you define to yourself and to them
  310. ;      precisely what you expect out of the partnership.
  311. ;      If you're not in a bargaining position you may give up
  312. ;      a lot, but you should still be able to gain a lot
  313. ;      (in terms of knowledge, although probably not in money).
  314.  
  315.  
  316.  
  317.  
  318.                         PAGE #7
  319. ;*************************************************************************
  320. ;*************************************************************************
  321. ;Seven - Critiques
  322. ;*************************************************************************
  323. ;*************************************************************************
  324. ;*************************************************************************
  325.  
  326.    Shadow Of the Beast
  327.       Pysgnosis of all Companies has the potential to put out the
  328.       best games, they finally got their programming act together
  329.       and combined with their tremendous graphics are now putting
  330.       out programs that run fast enough to play and look dynamic.
  331.       Yet they are still completely missing "minor" elements like
  332.       consistency of topic, atmosphere, theme and playability....
  333.       And the time delays here are something else also.  If they
  334.       used a simple sector based DMA driven disk read they could
  335.       probably get it so that you wouldn't notice the load lag.
  336.       I would say that it is the best arcade style game out for
  337.       the Amiga so far, in the Sword of Sodan vein.  With the
  338.       T-Shirt thrown in its a good buy. (PS Boot Disk #3 of S of S).
  339.  
  340.    Aztek MANX Assembler V4.x
  341.       Terrible, really quite bad, a really secondhand effort.
  342.       Incompatible, cryptic, buggy, slow, rudimentary.
  343.       Annoying because it has such potential.  To its benefit 
  344.       however it does offer a standard enviroment (ie assembling,
  345.       linking, includes, and CLI compatible), even with its
  346.       drawbacks, that have made it my solution to assembly language
  347.       programming for the past year.  Now I've just switched to
  348.       genim2 and am just realizing that Aztek wasn't very good.
  349.  
  350.    QuarterBack
  351.       Poor:  Difficult to find large
  352.       files that distort disk count.  Does not offer compression,
  353.       Does not holographically record master data to each disk
  354.       thus if disk #1 goes bad entire batch is lost.  Has option
  355.       (which is default) to turn off error checking.
  356.       However is the only backup solution available at the moment.
  357.  
  358.    CPR
  359.       Code Probe By Lattice has got to win the award for most
  360.       stupid interface.  Those flickery windows have got to be some
  361.       sort of acid burn test right?
  362.       I suggest Aztek SDB instead, cept its incompatible with the
  363.       known universe.
  364.  
  365.    WORDPERFECT
  366.       Arg....!
  367.       I'll bet that given one week on the Word Perfect Source
  368.       code I could get that thing to run an order of magnitude
  369.       faster just by fixing the screen i/o; replacing it with
  370.       custom 1 bitplane overscanned copperlist and text routines.
  371.       Still blows away most other Word Processors.
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.                         PAGE #8
  380.    POPULOUS
  381.       Ok graphics, nice integrated concept, where's the game?
  382.       Seems a bit slow, where's the blitter?
  383.       What would be really cool is if the lumpen-folk built
  384.       around roads, which could only be on flat land, not just
  385.       simply houses...oh well, its still an ok game.
  386.  
  387.    Lack of Definitive Desk Top Publishing Tools
  388.    Lack of Definitive Accounting Packages
  389.    Lack of Definitive Spread Sheet Packages
  390.  
  391.    What really bothers me about most the products, aside from
  392.    Shadow of the Beast is that the Developers know about conventional
  393.    programming practices, but do not understand even the simplest
  394.    things about interface design.  I personally dislike having to
  395.    switch between mouse, keyboard, joystick within the frame of
  396.    one mental operation.
  397.  
  398.    I also think that many of these products are compromised by trying
  399.    to follow the letter of the Amiga Workbench interface designs,
  400.    without thought to the original spirit; which is to make a
  401.    standard interface, which is visible, fun, fast and easy to use.
  402.  
  403.    CPR is probably the worst example of all the above, the Aztek
  404.    SDB is a beautiful piece of code, its a real credit to its developers
  405.    John3 could learn a lot by looking at that simple, elegant interface.
  406.  
  407.    I have to really say that I can't really be so critical.  The
  408.    tools which most these developers have to use are pretty bad, and
  409.    everybody is so busy making money that nobody stops long enough
  410.    to develop or market adequate tools themselves.
  411.  
  412.    And Commodore itself has been less than supportive of its
  413.    Developer Community...Most these Developers are working in greedy
  414.    isolation; clutching their feeble routines close to heart, one
  415.    protruding eye bleakly warding off possible threats.
  416.  
  417. Good Stuff:
  418.  
  419.    Dungeon Master
  420.       Sublime, completely sublime.  The animation sucks, but the
  421.       game is just phenomonal.  The best game ever made.
  422.  
  423.    ReSource, DevPac, CED, CMON,  - Sublime development tools.
  424.  
  425.    Dragons Lair II
  426.       Incredible, actually playable, branch points at different
  427.       places in the game completely destroy the myth of a single
  428.       memorized solution.  I find myself gasping as I try to
  429.       out-guess the next screen.  I love it. A complete contrast to 
  430.       SpaceAce which is basically an attempt to tear money out
  431.       of the market (SpaceAce was by David Fester-ing wound).
  432.       (DL II: Singes Revenge, is by Randy Linden)
  433.  
  434.    Matt Dillon, the guy is so prolific, that he counts as a good thing
  435.       in himself.  The quality and quantity of his work is
  436.       stupendous, and the fact that he releases source code is
  437.       the coup de grace.
  438.  
  439.    (Actually there are many people who I unabashedly admire, such as
  440.     Stephen Vermulen, Fred Fish, Chris Draco Grey, Randy Linden...)
  441.  
  442.  
  443.  
  444.  
  445.                         PAGE #9
  446. ;*************************************************************************
  447. ;*************************************************************************
  448. ;*****************,*******************************************************
  449. ;Eight - Communiques
  450. ;*************************************************************************
  451. ;*************************************************************************
  452. ;*************************************************************************
  453.  
  454.    Please don't send me software that I do not have legal permission
  455.    to use without pre-purchase.
  456.  
  457.    The Source Code in Tetris is entirely my own work.  I am no longer
  458.    owned by a corporate think-tank, and none of the work here compromises
  459.    any technologies that they own.  You are free to disseminate Tetris
  460.    as widely as possible.  I have no malicious intent against any of
  461.    the many previous companys I have worked for.  My attitude is that
  462.    I can simply outperform any individual or corporate group that has
  463.    decided to (for example) not pay me, or not meet contract demands.
  464.    Honor is very important to me in an industry where so many people
  465.    seem dishonorable.
  466.  
  467.    I am not responsible for any problems you have with Tetris, Tetris
  468.    is entirely a public domain work, and as such I am not liable for
  469.    any bugs Tetris has or deaths that Tetris may cause in your family.
  470.  
  471.    If you find any bugs in Tetris please fix them and send me a copy.
  472.    If you have the impetuous please add a dancing lego-man to tetris.
  473.  
  474.    I'm always looking for people to work for me, or people for whom I
  475.    could work.  If you're interested or interesting, or you just have
  476.    some questions feel free to send me a message.
  477.  
  478.    I have all kinds of interesting projects and subroutines.
  479.  
  480.    Unlike othe people (whom we won't mention here) I'm always willing to
  481.    discuss my ideas on programming strategies, politics, and money.
  482.    (Of course I can't discuss areas related to current contract work).
  483.  
  484.    I have a group of people I am now working with, we are a loose
  485.    collective of programmers, with experience and contacts in the
  486.    industry, and I am always willing to put you in touch with the
  487.    company or group best suited to releasing your products.  I might
  488.    even be willing to help you write a project, for free if its
  489.    a purely technical issue where I can just code your solution.
  490.  
  491.    If anything I think I can suggest abstract approaches for general
  492.    program design, which I consider to be my forte (You must sign
  493.    a non-disclosure with me however, before discussing any of your
  494.    ideas; this protects you).
  495.  
  496.    I also love to get demos and utilities!  One of the projects which
  497.    I've wanted to do for about 3 years now is a vector-tilemap game,
  498.    more commonly known as vectorballs.   A kind of 3D Emerald Mines.
  499.    I played around with the math in Vortex a bit (see the very first
  500.    title page for example) and I think I could produce an entire game
  501.    around the concept.  So I'm always happy to get demos which
  502.    demonstrate particular approaches like that.  My favorites are the
  503.    RED-SECTOR vectorballs demo and I also like the PARANOIMIA vector-
  504.    ball-text demo (although I think PARANOMIA/QUARTEX are losers for
  505.    selling cracked games).
  506.  
  507.    If you have any demos, utilities or source code to exchange with
  508.    me you can mail me at this address:
  509.          Andy Hook
  510.          c/o The Computer Shop
  511.          3515 18th St Sw
  512.          Calgary, Alta, CANADA!!!!
  513.          T2T-4T9
  514.  
  515.                   Yours Truly
  516.                   Anselm Hook
  517.  
  518.    P.S. Although LLaama soft may recomend Godel Esher Bach I would suggest
  519.    Metamagical Themas Jeff!
  520.  
  521.    Appendum Feb 18 1990:
  522.  
  523.    I tried to fix 2 bugs, 1) With a 68030, Kick 1.3, Custom Font the
  524.    tetris text is reported to be bad.  2) Workbench support.
  525.  
  526.